WIP: NTRU Prime #35
WIP: NTRU Prime #35
Conversation
|
At this point streamlined ntru implementation is almost compete and what is left is fixing some maths bugs in decap and making sure that all NIST tests are passing. then I have to slowly rework the API while making sure that all tests still pass |
This patch creates empty crate for ntru prime and adds test data taken from nist Signed-off-by: Ahmed <>
1- compile for no-std 2- allow some warnings, while being pedantic regarding other warnings Signed-off-by: Ahmed <>
That include 1- constant time if else 2- constant time division 3- constant time bitonic sort Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
Signed-off-by: Ahmed <>
|
So working implementation should be complete at least for streamlined ntru including tests. API is less than ideal and comes with no documentation and does not use the KEM crate. also LWE variant is not implemented yet. I will try to move 87c7c02 to subtle, I am not sure if they would be interested in having sorting algorithm there. |
|
@oddcoder sorry this one went by the wayside. Can you rebase? |
|
Hi, sorry for long delay, right now I am relocating from one city to another, I will get back to this pr in 2~3 weeks |
|
@oddcoder I took a look at trying to get this merged but it seems there are quite a few sizes that need to be added to Edit: aah, that was RustCrypto/hybrid-array#79. I got fairly far adding all the sizes needed for NTRU, but wanted to make sure I wasn't duplicating effort. |
2 participants
Aside from finishing the implementation few things that I would like to also do
1- adapt/move the whole constant_time module to
subtle.2- more tests (& fuzzing when the input space too big to exhaust) to algebra since most of it is not tested and I found lots of bugs in the parts I tested.
3- add benchmarks.
4- see if replacing loops with maps improves performance considerably.
5- more
debug_assertsI will probably take a full round of revision following the specs and the sage implementation to see what properties should hold where.Things I am not confident about:
1- the down casts (i32 to i16 ...etc)
2- the casting across signs (i32 to u32....etc)